1. Field of the Invention
The present invention relates generally to communications networks and in particular, to a method for adapting multi-user multimedia data in a communication system.
2. Description of Related Art Including Information Disclosed Under 37 CFR 1.97 and 1.98
Universal Mobile Telecommunication System UMTS is being developed to offer wireless wideband multimedia service using Internet protocol. The UMTS as a third-generation 3G mobile communication combines streaming with a range of unique services, like for example geographical positioning, to provide high-quality Internet content to the users. Images, voice, audio and video content are example of mobile multimedia services, which are delivered to the users via media streaming and download techniques. It means once the content has been put onto a media server, it can be delivered on-demand via download or streaming. To download content, the user clicks on a link and waits for the content to be downloaded and playback to begin. Download capabilities are easy to integrate since the hypertext transfer protocol (HTTP) can be used for downloading files. To access streaming data or general speaking multimedia data, the user clicks on a link to start playback, which is almost immediate. Because streaming is a semi-real time service that receives and plays back data at the same time, it puts greater demands on protocols and service implementation, especially when the service is to work over networks with little or no quality of service, like this is the case in UMTS. The radio resources, which are used on the last part of a transmission is to be used in a better way.
Currently work is being done to introduce broadcasting and multicasting into WCDMA and GSM wireless networks. Both broadcast and multicast provide transport efficiency and reduce the load on the content servers, like for example the streaming servers. Additionally solutions are being worked out for performing streaming or general formulated multimedia transmission in a wireless network. In the following the corresponding architectures are presented.
The FIG. 1 shows the current so-called Multimedia Broadcast/Multicast Service (MBMS) architecture. In the following merely the most important nodes and examples of the different access networks, like UTRAN, GERAN, connecting the end user UE are mentioned. The access networks are handled by means of a serving node, SGSN that communicates with an edge node, the GGSN that is responsible for connection to the external networks, like Internet. The BM-SC entity connected to GGSN is responsible for the provision of multicast/broadcast, like for example for bearer establishment and data forwarding. BM-SC offers interfaces to a content provider, so that said content provider can request data delivery to the users. The BM-SC may authorise and charge content providers.
In order to keep the solution simply, it is foreseen currently on the radio network part to support only a downlink channel for data traffic going to the end user UE. It means there is no uplink channel in an access network, which can be used by the end users UE to send for example reports regarding the quality of receiving.
The transmission of the multimedia flow for a single user is performed in a wireless network by means of a Packet Switched Streaming architecture. Said architecture is depicted in FIG. 2. It shows streaming client being connected via an access network, like UTRAN or GERAN with an UMTS Core network. In the UMTS two important kind of nodes are depicted, SGSN and GGSN. The SGSN is a serving node for handling the to the access networks attached users. The GGSN is responsible for connection to the external networks, like IP Network. For the purpose of multimedia provision there are different entities in the IP network, like content server being responsible for providing multimedia data.
The multimedia data is distributed by means of multimedia protocols. The FIG. 3 shows a protocol stack with the protocol layers responsible for multimedia transmission, Real-time Transport Protocol RTP. The RTP uses Universal Datagram Protocol UDP as a transport protocol appropriate for transmission of streaming data, because UDP provides a fast transmission although not reliable like it is the case by Transmission Control Protocol TCP. HTTP and Real-Time Streaming Protocol RTSP run over the reliable TCP. The RTSP provides session control for streaming sessions. HTTP is used for transmission of still images, bitmap graphics and text.
The RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. The functions provided by RTP include payload type identification, sequence numbering, timestamping, and delivery monitoring. The RTP contains a related RTP Control Protocol RTCP augmenting the data transport, which is used to monitor the QoS and to convey information about the participants in an ongoing session. Each media stream in a conference is transmitted as a separate RTP session with a separate RTCP stream.
RTP adds a time stamp and a sequence number to each UDP packet in a special RTP header. The time stamp is related to the sampling or the presentation or composition time of the media carried in the payload of the RTP packet. It is used for playing back media at the correct speed, and together with RTCP, it is used for synchronizing the presentation of other streaming media. A payload specification defines the interpretation of the time stamp and other RTP fields. The recipient uses the sequence number to detect the loss of packets statistics on loss can be reported to the server by means of RTCP.
RTCP reports provide statistics about the data received from a particular source, such as the number of packets lost since the previous report, the cumulative number of packets lost, the interarrival jitter, etc. An additional draft defines a format for extensions to the RTCP sender and receiver reports. A detailed description of RTCP can be found in RFC 1889, Chapter 6. The RTCP control protocol is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP.
The primary function of RTCP is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols. The feedback may be directly useful to diagnose faults in the distribution. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. With a distribution mechanism like IP multicast, it is also possible for an entity such as a network service provider who is not involved in the session to receive the feedback information and act as a third-party monitor to diagnose network problems. This feedback function is performed by the RTCP sender and receiver reports. The RTCP specification requires that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant sending its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent.
Furthermore the RTCP has an optional function to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in sessions where participants enter and leave without membership control or parameter negotiation. RTCP serves as a convenient channel to reach all the participants, but it is not necessarily expected to support all the control communication requirements of an application. A higher-level session control protocol, which is beyond the scope of this document, may be needed.
The above described functions, besides the last one being optional, are mandatory when RTP is used in the IP multicast environment and are recommended for all environments.
Therefore the multimedia service in wireless network is to be used as well for a single user, the so-called unicast connections but all above for a group of users, the so-called point-to-multipoint or even multipoint-to-multipoint connections. The point-to-multipoint services require high demands on the network infrastructure and consume considerable amounts of bandwidth. Some examples of such services are video-conferencing, whiteboarding, real-time multi-user games, multimedia messaging, virtual worlds. This kind of multimedia applications uses for transport broadcast or multicast mode. Broadcast has the possibility of addressing a packet to all destinations by using a special code in the address field. When a packet with this code is transmitted, it is received and processed by every user on the network. This mode of operation is called broadcasting. Multicasting supports transmission to a subset of the users. Each can register to a multicast group. When a packet is sent to a certain group, it is delivered to all users registered to that group.
The RTCP has mechanisms for reporting in case of multicast sessions. However, in case of radio networks the multicast reporting waste air interface resources and potentially overloads the network servers. Furthermore, in the preferred multicast solution there is only a downlink and no uplink channel. This implies that the users cannot send RTCP reports to the source.
In RFC 1889 there is an entity, the so-called mixer introduced. The mixer receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source. Therefore the mixer creates a new message being a combination of the received messages.
However, for the current RTP the use of RTCP receiver reports is mandatory in multicast sessions. In particular it is important that the multicast sender receives these reports to signal that clients are still listing. The current revision of the RTP provides a feature to suppress RTCP receiver report usage. However, by omitting RTCP receiver reports also an important means of getting quality feedback from the receivers is omitted. The source cannot adapt to changing conditions and also cannot provide alternative streams.
It is anyhow questionable what the source should do if an RTCP report from a single client indicates that several RTP frames were corrupted or lost and that client would better be served with a lower data rate. This is especially a big question mark in wireless networks with increasingly heterogeneous users. The multimedia users are characterized by a variety of mobile terminals with a wide range of display sizes and capabilities. In current multicast solutions the source will either ignore such reports or adapt to the slowest receiver. Both are not adequate when clients are charged for the service and the bearer that is used for the service. In addition different radio-access networks make multiple maximum-access link speeds available. Because of the physical characteristics of cellular radio networks, the quality and, thus, the data rate of ongoing connection will also vary, contributing to the heterogeneity problem.
Therefore the following problems occur regarding the RTCP reporting in multicast sessions in wireless networks. The scarce radio resources are used inefficient, when every user sends a RTCP report. This can also leads to overload of servers, like RNC, SGSN, GGSN, for example in case the reports are generated by a high number of users, for example in a football arena. Because of the heterogeneous networks the source must adapt to slowest user. Further because of the higher number of reports and the long time needed for evaluation of the reports a long delay is generated before the source is aware of a problem. Further the RTCP reports do not contain all necessary information for wireless networks